Communication networks are evolving from circuit switching (Circuit Switching, “CS” for short) networks to packet switching (Packet Switching, “PS” for short) networks over the Internet Protocol (Internet Protocol, “IP” for short). In carrier-class services provided by the IP network, it is essential to consider end-to-end quality of service (Quality of Service, “QoS” for short) to meet communication quality requirements of the user, especially in real-time services such as video calls and online games. In view of the QoS requirements of the service, the 3rd Generation Partnership Project (3rd Generation Partnership Project, “3GPP” for short) defines a policy and charging control (Policy and Charging Control, “PCC” for short) architecture.
In a PCC architecture, to meet the QoS requirements of specific service flows, the following procedure is generally applied: An application function (Application Function, “AF” for short) entity sends an authentication authorization request (Authentication Authorization Request, “AAR” for short) message to a policy control and charging rule function (Policy control and Charging Rule Function, “PCRF” for short) entity, where the AAR message may carry service information such as the IP address, the port number and the media type of an IP flow, and the corresponding QoS requirement such as bandwidth information; the PCRF stores received service information, and generates and stores a new PCC rule according to service information, subscription information, operator configuration, and other information received from a policy and charging enforcement function (Policy and Charging Enforcement Function, “PCEF”) and the AF; the PCRF sends a re-authorization request (Re-Authorization Request, “RAR” for short) message to the PCEF, where the RAR message carries new PCC rule; the PCEF loads and executes the PCC rule, and performs policy and charging control on the service data flow; if no IP-connectivity access network (IP-Connectivity Access Network, “IP-CAN” for short) bearer meets the QoS requirements in the PCC rule, a new IP-CAN bearer that meets the requirements is created between the PCEF and the access network, where the QoS class identifier (QoS Class Identifier, “QCI” for short) of the bearer is a QCI parameter in the PCC rule; the PCEF returns a re-authorization answer (Re-Authorization Answer, “RAA” for short) message to the PCRF; and the PCRF returns an authentication authorization answer (Authentication Authorization Answer, “AAA” for short) message to the AF. In this way, IP-CAN bearers of different QCI parameters are created to meet QoS requirements of different services.
The application layer is concerned with an end-to-end delay, that is, the delay from a user equipment (User Equipment, “UE” for short) to an application server. In the prior art, the PCRF generates the QCI in the QoS policy according to only the service type or the application layer delay requirement, but the QCI does not necessarily meet application layer requirements. For example, the delay upper limit of the application server is 120 ms, and the PCRF generates QCI=1, which corresponds to a delay of up to 100 ms. In fact, the delay from the application server to the PCEF is 40 ms. Therefore, QoS policy does not meet the application layer delay requirement.
In addition, once the QoS policy is generated, it is deemed that the network meets the application layer delay requirement. In fact, due to user mobility and the network state, it is possible that the initial QoS policy meets the delay requirement at the beginning but the network is unable to meet the transmission delay requirement of the service flow subsequently for reasons such as switching between access networks or congestion of radio resources, which leads to poor user experience.